…3583)

The i18n gate only ever ran forward: `os i18n check` asks which keys the
metadata expects that no bundle carries. Nothing asked the reverse — which
keys a bundle carries that no metadata claims — though the spec already names
the answer (`TranslationDiffStatus 'redundant'`, `redundantKeys`), both
declared with no producer.

That direction ships two failure modes, both in the HotCRM audit: bundles keyed
to fields an object no longer declares, and option translations keyed by the
display label or a variant spelling of the stored value (`direct-mail` for
`direct_mail`, `planned` for `planning`). Neither breaks anything — the
resolver finds nothing and renders the source string, so the screen looks
translated while one field quietly is not.

`validateTranslationReferences` walks every bundle in `stack.translations`
against the stack it ships with — objects, fields, option values, views,
actions and their params, sections, apps and nav ids, dashboards, widgets,
header actions, global actions — wired into `validate`, `lint` and `compile`.
All findings are warnings: an orphan key is inert, not broken.

Cross-package objects keep the S3 rule: a registered platform object is
skipped wholly (its fields are invisible to a stack lint), an unregistered
platform-prefixed name is reported once on the object key, and no subtree is
half-checked. `messages`, `validationMessages`, `settings`, `settingsCommon`
and `metadataForms` are deliberately unjudged — their keys belong to code,
plugins and the platform registry, so there is no universe to resolve against.

Two example apps carried the exact bug class and are fixed at the producer:
app-crm translated `account_id`/`contact_id`/`opportunity_id` (fields are
`account`/`contact`/`opportunity`), `first_name`/`last_name` on a lead that
declares `name`, two sections nothing declares, and app `crm` (it is
`crm_app`); app-todo keyed every bundle to `task` while the object is
`todo_task` — 92 strings that looked translated were unreachable, which the
coverage ratchet now records. Its completeness test hard-coded the same wrong
key, so it stayed green against a bundle no resolver could find; it now reads
the key from `Task.name`.

Verified: lint 492 / cli 673 tests pass; the rule reports zero findings across
app-crm, app-showcase and app-todo after the fixes, having visited 274 field
keys, 94 option keys and 5 app keys over 35 object nodes — a floor with
substance, not an empty walk.

Refs #3583

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015r31hzuSN19iK8ATRPcCpS

…alidation-midr20

# Conflicts:
#	scripts/i18n-coverage-baseline.json

…st it (#3583)

Running the new rule over HotCRM (~18k lines of shipped metadata) reported
~40 `_views` keys as orphans. Every one of them was correct; the rule was
wrong, in two compounding ways:

1. A view record is a CONTAINER, not a view. The default list lives at `list`
   and the named tabs at `listViews.<key>` / `formViews.<key>`, each of which
   may also carry its own `name`. Collecting only the record's own `name`
   makes every named tab look undeclared.
2. The object binding lives INSIDE the container (`list.data.object`), not at
   the record root. The record-level lookup resolved to nothing on the
   canonical shape, so the whole record was skipped — which is why the
   universe was empty enough to report the app's entire view surface.

The examples missed this because none of their bundles carried `_views` keys
at all: the walk was exercised, but that one branch of the universe never
was. A corpus with the keys present is what caught it — §6.1's point about a
false-positive floor only meaning something when the walk is non-empty applies
per branch, not per rule.

`collectViewRecord` now registers each container under the object THAT
container binds (falling back to the record, then to the default list), and
accepts both the map key and the inner `name` — authors write either, and the
key is what the console renders the tab from. Form sections are collected in
the same pass, so `_sections` gets the same binding fix. Objects carrying
views directly (`objects[].views`, `objects[].listViews`) go through one code
path with the owner pinned.

Three regression tests pin the HotCRM shape.

Residual on HotCRM after the fix: 6 findings, all true —
`apps.crm_enterprise.navigation.group_products` and `.group_analytics` across
three locales, where the app declares group_sales / group_work /
group_marketing / group_service / group_insights and neither translated id
exists.

Refs #3583

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015r31hzuSN19iK8ATRPcCpS